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MANAGING THE COMPUTER WORKLOAD 


Yes, distributed systems, interactive systems, new net- 
work services, and so on, are getting most of the attention 
in the computer field these days. But many organizations, 
in developing their data processing plans for the next five 
years or so, have found that the bulk of their computer 
workloads will continue to be ‘plain old batch processing.’ 
The interactive workload is growing rapidly, but batch 
seems to be growing at least as fast. Some (and often a lot) 
of this batch workload will be entered via remote batch 
terminals. There are tools and techniques available to aid 
in managing this workload—for determining needed capac- 
ity, for scheduling daily production, and for handling per- 
turbations in the workload. Here are some user experi- 
ences. 


ake Standard Oil Company of Cali- cated throughout the United States and 
fornia (Chevron), with headquarters in San Canada. 
Francisco, is a major energy producer and 
distributor serving world markets. Annual 
sales are about $30 billion; Fortune maga- 
zine lists the company as the sixth largest 
U.S. industrial firm. Chevron employs over 
38,000 people. 

Chevron spent much of the 1970 decade 
in consolidating its data processing 
workload into two large computer centers 


The main incentive for this consolida- 
tion was, as is so often the case, the desire 
to greatly reduce the incompatibilities of 
programs and data files that developed 
during the 1960s. That consolidation has 
been completed. Now the people in Chev- 
ron data processing are detecting a grow- 
ing interest among the users in distributed 


in the San Francisco Bay area. In these 
two centers, there are a total of seven 
large IBM computers (models 3033, 168, 
and 158), plus two Amdahl Vé6s and one 
V7. Most of the input for these centers 
comes from remote batch terminals lo- 


systems. But they want to move cautiously 
in this direction, to avoid having incom- 
patible systems develop all over again. So 
centralized batch processing will continue 
to be a prime workload within Chevron 
for some years to come, though distributed 
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systems will be installed in the next few 
years for some applications. 

The workload on the IBM machines at 
the two centers consists of the following 
two components. 

Scheduled daily production. This is the 
predictable part of the workload, made up 
of application systems that are run on a 
scheduled basis (daily, weekly, etc.). Chev- 
ron runs about 16,000 jobs a month of this 
category; these jobs, in turn, make up 
about one-third of the batch computer 
workload. 

Most of this scheduled work is run on 
the evening and night shifts, local time. 

Unscheduled work. This part of the 
workload is made up of jobs that users en- 
ter as their needs dictate. It consists of (1) 
production jobs run as needed, (2) program 
development, test, and execution of “one- 
time’ jobs (such as engineering calcula- 
tions), (3) the development and mainte- 
nance of application systems, (4) database 
queries and updates (about 90,00 per day), 
and (5) a relatively small amount of time- 
sharing (Tso) for system software program- 
mers. (The bulk of the company’s time 
sharing service is provided via National 
ee software run on the Amdahl comput- 
ers. 

Let us look at how Chevron manages 
the scheduled portion of this workload. 


Scheduling daily production. Chevron has 
been using the os/vs scheduling system 
from Value Computing Inc. since 1978. 
Previously, the company had used another 
scheduling system, but encountered trou- 
ble in making it work and in getting 
needed support. They then investigated 
other offerings on the market and picked 
the VCI system. “Since then, the Value 
system has done the job we expected it 
to,” we were told. 

When a new application is first set up 
and is going into production, a written 
agreement is made between computer op- 
erations and the user department. This 
agreement defines the job characteristics, 
such as the general amount of the input, 
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when that input can be supplied, when the 
results are needed, and so on. Using the 
VCI scheduler, this new workload is fitted 
into the production schedule. At this 
point, computer operations can tell the 
user just when the input must be supplied, 
if the results are to be delivered on time. 

At the two Chevron centers, the com- 
puter operations people are not job sub- 
mitters. The users are responsible for sub- 
mitting jobs, according to the schedules 
they have been given. The users must also 
submit any necessary date cards, JCL input, 
and so on. The two centers do have the 
position of “batch job monitor’; the person 
filling this position can see (via a terminal) 
what jobs are in the input queue at any 
time and can compare this list with the 
printed schedule for the day. But the users 
have the main responsibility for seeing 
that their work gets into the input queue 
on time. 

Of course, not all of the scheduled work 
runs as planned. Schedule changes can and 
do occur. These come about generally 
from user requests or from job characteris- 
tic changes. Let us consider those changes. 

User requested changes. Some of the 
user requests involve permanent changes. 
Examples include application systems that 
have been enhanced or modified, at user 
request, that lead to a change in their pro- 
duction schedule. In other instances, the 
application systems are satisfactory but the 
users want to change the times that they 
submit input or receive output. Other user 
requests involve temporary changes—input 
may be late in arriving on a certain day, or 
an extra edit run is needed, or such. Gener- 
ally, the user department contacts com- 
puter operations when things like this oc- 
cur, to see when their work can be fitted 
into the workload. Because of the large 
amount of capacity for handling unsched- 
uled work, computer operations generally 
can fit such work into the workload fairly 
promptly. 

Job characteristic changes. Most of the 
scheduled jobs have fairly stable charac- 


teristics, including volume of input. But 
some jobs do vary significantly in the 
amount of computer resources they con- 
sume. The VCI scheduling system keeps 
track of the actual job times and compares 
them with the expected job times—and ad- 
justs the expected times as necessary. 
Based on the new expected times, the 
scheduling system may determine that in- 
put must be provided, say, earlier than 
previously, if the output schedule is to be 
met. Messages to this effect are automati- 
cally sent to the user departments. 


Planning computer capacity. The ques- 
tion here is: how much computer capacity 
will be required each year, for the next 
two to five years, in order to handle our 
workload? 

Because two-thirds of Chevron’s 
workload is unscheduled, this portion of 
the workload dominates the capacity plan- 
ning question. For this part of the 
workload, the planners look at usage 
trends over the past several years, and ex- 
trapolate those trends a few years ahead to 
get the basic growth. Any large new types 
of unscheduled usage are also considered. 

For the scheduled workload, the plan- 
ners look at the usage trends plus any new 
applications that are expected to be added. 

Based on these calculations, the amount 
of additional capacity and the time when 
it will be needed are determined. 

Chevron has not made much use of the 
VCI scheduling system for estimating fu- 
ture capacity requirements, we were told. 
If the scheduled workload made up, say, 
three-fourths of the total workload, then 
such use of the system might be helpful by 
using it to simulate conditions at future 
points in time. 

There have been some cases, though, 
where Chevron has made use of this simu- 
lation feature. In one instance, a remote 
data center was being phased out and the 
work transferred to one of the central 
sites. This workload had a tight daily 
schedule and involved a good deal of mag- 
netic tape processing. A VCI workload 
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control file was set up for this work, and 
was then tested against the workload con- 
trol files of the two main centers, to see 
which center could best handle the new 
work. 


Standard Oil Company of California is 
handling a large and growing computer 
workload. A fair amount of this workload 
is of a predictable nature, and the com- 
pany has found the VCI os/vs scheduling 
system provides an effective way to man- 
age the daily production of this workload. 


The workload structure 


Before discussing computer workload 
management, it would be useful to identify 
the major types of work that data process- 
ing systems will be asked to perform in the 
future. We see four main components of 
the total workload: (1) system overhead, 
(2) batch workload, (3) interactive 
workload, and (4) computer message sys- 
tems. 


System overhead. It may seem incongru- 
ous to start out this discussion with the 
overhead item. But this item tends to be 
overlooked in discussions of workload. As 
computer systems take on more complex 
functions, the overhead goes up. Central 
system overhead may well be one of the 
prime factors that encourages users to get 
their own (distributed) systems. 


System overhead includes the resources 
used by the operating system, database 
management system, communications ex- 
ecutive, scheduler, job accounting system, 
checkpointing, rollback and recovery, re- 
runs, makeups, and so on. The goal is to 
minimize the system resources consumed 


by these things. 


Batch workload. This workload includes 
both locally and remotely entered work 
that is to run in a batch environment. Jobs 
are put in an 7 queue and are worked 

ae generally) in turn. There are several 
aaa types of work that make up the 
batch workload. Here are some. 


Streams of jobs, with precedence rela- 
tionships—the characteristic of most batch 
data processing applications. ‘Payroll,’ for 
instance, involves a series of jobs, starting 
with a variety of inputs and ending with 
many outputs, one of which is paychecks. 
The jobs must be done in a logical man- 
ner, such as validating input before files 
are updated. 

‘Spooling’ of input/output. Since input/ 
output devices are much slower than the 
computers (usually), the input/output op- 
erations are batched and performed sepa- 
rately from the updating runs. 

Program development and test that is 
performed in a batch environment, with 
batch compilations and executions. 

‘Short cycle’ batch processing, to ap- 
proximate interactive service but with less 
expense. Transactions are accumulated for 


a short period of time (say, a few minutes) 


and then processed in a normal batch man- 
ner. 

Report preparation, where a report re- 
quires the computer to examine some sig- 
nificant portion of a whole file. 

These types of work make up most of 
the ‘plain old batch workload.’ 


Interactive workload. This workload is 
both entered and the work initiated by the 
terminal user. Computer resources may be 
shared among a number of users simulta- 
neously, where each is given the resources 
for very short periods of time, until their 
jobs are completed. We see this interac- 
tive workload as consisting of seven com- 
ponents. 

On-line updates. Input transactions are 
validated as the user enters them and then 
the affected file records are updated imme- 
diately. Much of the use of micro-comput- 
ers in data processing is of this variety. 

Retrievals for queries and prepared re- 
ports. This will be a large component of 
future workloads, in terms of the number 
of requests processed. It involves the re- 
trieval and display of designated data rec- 
ords or report pages. 
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Graphics output to CRT terminals. More 
and more use will be made of graphics for 
the presentation of report data. We be- 
lieve that most such graphic outputs will 
commence to be prepared immediately af- 
ter the user request has been entered. 

Report preparation. As we have been 
discussing in recent issues, computer sup- 
port for management will provide for on- 
line preparation of reports. The examina- 
tion of a file will commence when the user 
requests it, not when a batch scheduler 
says it will commence. 

Time sharing calculations. Conventional 
uses of time sharing—including the use of 
pre-programmed routines and models—will 
continue to grow. 

On-line program development. More and 
more program development will be trans- 
ferred from a batch to an on-line environ- 
ment, as we discussed in our October and 
November reports. 

Text editing, used for the preparation of 
reports, memos, letters, and so on, will 
certainly grow in use. One main use will 
be in conjunction with computer message 
systems. 


Computer message systems. These systems 
represent the fourth major workload cate- 
gory for future computer use. We dis- 
cussed these systems in our April 1977, 
September and October 1978, and May 
and September 1979 reports. This amount 
of discussion indicates the importance we 
attach to these new ‘electronic mail’ sys- 
tems. They will become significant users of 
computer resources. 

With all of this expected growth in the 
interactive and computer message 
workloads, why does batch processing con- 
tinue to be important? Why isn’t it gradu- 
ally being displaced by these “more mod- 
ern’ methods? 


Why batch? 


Some of our friends who work for large 
companies have pointed out an interesting 
fact to us. In the planning for the use of 
programming talents for new applications 


over the next several years, most of the 
programmer time will be going for batch 
applications, not interactive. This is not 
the maintenance of existing batch applica- 
tions that they are talking about; rather, it 
is the development of new applications 
that users have requested. 


Why this continued demand for batch? 
We see three main reasons. 


Processing that is time-related. Much of 
the data processing that organizations 
need is time-triggered. Cycle billing, pay- 
roll, month-end reports, financial period 
closings, and bank check processing are ex- 
amples. People have become accustomed 
to operating this way, so that time-trig- 
gered processing will continue. 


It is true, of course, that this type of 
batch processing can be combined with in- 
teractive processing. Transaction data can 
be entered interactively and either posted 
to the files or or accumulated. Then, when 
the proper time arrives, the transactions 
are posted, if needbe, and the file is pro- 
cessed to produce the needed outputs. 


Processing that is event-triggered. An ex- 
ample of what is meant by this is the large 
file that is used only infrequently to pro- 
duce outputs, although inputs flow in reg- 
ularly. Data entry might be performed on 
the inputs, after which they are accumu- 
lated until a request for output is received 
(the triggering event). Then the file is up- 
dated and the output produced. 


Economy. Interactive use is nice, but it 
does use more computer resources (usu- 
ally) than batch. As mentioned earlier, 
short cycle batch might be used instead of 
an interactive system, if a short time delay 
can be tolerated. Where such economies 
are significant, batch processing will con- 
tinue to be used. 

So, all in all, batch will continue to con- 
stitute a large portion of the total com- 
puter workload as far ahead as we are able 
to see. 
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Workload management 


The problem of computer workload 
management is concerned, to a great ex- 
tent, with the question of how best to use 
shared resources. Most of today’s com- 
puter-using organizations have some form 
of centralized data processing which 
serves a number of user departments. This 
centralized data processing will not be re- 
placed in short order by distributed 
processing wherein each user department 
has its own computer. The management of 
shared resources will continue to be a 
challenging problem area. 


A decreasing percentage of today’s com- 
puters, we believe, provide only batch 
processing. More and more of them are 
also providing some types of interactive 
service, such as a query service and/or a 
time-sharing service. The batch work also 
may consist of both scheduled and unsch- 
eduled work. 


For the scheduled batch component of 
the workload, automated aids are available 
for helping management make efficient use 
of the resources. 


For the unscheduled work—both batch 
and interactive—management must pro- 
vide sufficient capacity for handling some 
arbitrary peak load conditions. A charging 
mechanism also is usually needed, with in- 
creased charges during peak load periods, 
as a means for load levelling. 


So the main elements of workload man- 
agement include: 


e Capacity management 
e Charging for services 
e Daily production management 


This whole subject area is complex, and 
covers more material than is appropriate 
for one issue. In this report, we will con- 
sider the first two of these elements—ca- 
pacity management and _— charging 
methods—only briefly, and will concen- 
trate on the management of daily pro- 
duction. | 


Capacity management 


The two major questions facing data 
processing management in connection 
with computer capacity, are: How much 
capacity do we currently have? How much 
capacity will we need, and when, to han- 
dle our anticipated workload? 


These questions are very difficult to an- 
swer with much precision. It is hard to 
know the ‘capacity’ (the total amount of 
work that can be performed) of an existing 
configuration. It is even more challenging 
to try to figure out the capacity of a hypo- 
thetical configuration. 


Why is this the case? The reason is, ca- 
pacity is a function of many variables, and 
it is often not easy to know the values of 
those variables in an existing configuration 
or to know how that capacity will change 
if some rather minor changes are made in 
the variables. Another block of memory, 
or an additional input-output channel, 
might greatly increase the capacity of a 
particular configuration, while changing to 
higher speed tape units might do little. 


If it is difficult to assess the real capacity 
of an existing hardware/software configu- 
ration, think how much more complex it is 
to try to estimate the capacity of some fu- 
ture configuration. There are three situa- 
tions, each harder to estimate accurately 
than the previous. The first situation is 
where the user is considering adding, or 
changing to, a known hardware/software 
complex—a configuration that is in field 
use. In this case, the hardware and soft- 
ware parameters are more likely to be 
known. In the second case, the user is con- 
sidering installing an announced but not 
yet delivered configuration that will be 
used to replace or augment the existing 
configuration. Here the user has only the 
supplier's sales claims to use instead of 
measured parameters. In the third situa- 
tion, the user is considering an unfamiliar 
hardware/software complex—as in the 
case of installing a new distributed system. 
Here the user is in almost completely un- 
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familiar territory, so that errors of estimate 
are to be expected. 

The other side of the coin is the future 
workload—the demand for capacity. It, 
too, is hard to predict accurately. For in- 
stance, some of today’s batch systems will 
be converted to interactive, or to 2 combi- 
nation of interactive and batch. Com- 
pletely new uses, such as computer mes- 
sage systems, may be requested on a rather 
short lead time basis. Mergers and acquisi- 
tions can increase transaction volume; the 
sale of divisions of a company can reduce 
them. And so on. 

The customary solution for determining 
the computer capacity that will be needed 
in the future is to assume that capacity has 
been used efficiently in the past. Capacity 
trends can then be determined for the past 
several years and projected for several 
more years into the future. This approach 
can lead to over-capacity, especially if cur- 
rent capacity is not used efficiently. 

Another solution has been to develop a 
‘benchmark’ workload that can be run and 
measured on an existing configuration. Us- 
ing this as a starting point, the relative ca- 
pacity of other configurations can be de- 
termined by running the same benchmark 
workload on those configurations. This ap- 
proach has the advantage of bringing some 
unsuspected bottlenecks to light. And it 
does provide hard figures for estimating. 

But there are some problems with the 
benchmark approach. For one thing, the 
benchmark workload must be representa- 
tive of the total workload, and therefore 
has to be developed. It is not easy to make 
it truly representative, and it can be costly 
to develop. It probably must be based on 
the existing workload and may not con- 
sider important future applications. And it 
requires that the new hardware/software 
be available, for running the benchmark 
workload. 

There are two other approaches to ca- 
pacity management that we have come 
across—the BGS Systems, Inc. BEST/1 ana- 
lytic model approach, and the Institute of 


Software Engineering software physics ap- 
proach. 


Before beginning a brief overview of 
these two approaches, we should mention 
that we have had some discussions with 
users of both. The users have seemed well 
satisfied. But we have not yet had a chance 
to study the use of these methods in detail. 
We hope to do so for a not-distant future 
issue. In the meantime, we will confine 
ourselves to the following overviews. 


Analytic model approach. Brst/1, which 
uses the analytic model approach, is a pro- 
prietary software system developed by 
BGS Systems, Inc., of Lincoln, Massachu- 
setts, for evaluating and predicting com- 
puter system performance. For more infor- 
mation on it, see Reference 2. 


BEST/1 uses a queueing theory model for 
predicting the processing time for streams 
of jobs; it is not a simulation model. Be- 
cause of its analytic nature, it requires far 
less computer time to perform an analysis 
than does a simulation model that ad- 
dresses the same level of detail. 


To use BEST/1, the first step normally is 
to define the current computer workload. 
The different types of transactions are 
identified, as well as their flow through the 
system. The resources that each transac- 
tion type uses are identified, using ac- 
counting packages, hardware and software 
monitors, etc. The expected growth in vol- 
ume of the current workload, over the 
time period under study, is estimated. The 
expected new workload is analyzed in the 
same way. Similarly, the hardware and 
software parameters, for both current and 
future models, is determined. 


This data is then input to BEST/1. BEST/1 
determines the probable service time for 
each part of the workload. The model is 
tested by calculating the time required to 
process the current workload, and then 
comparing this estimate with actual times. 
After any needed revisions are made, the 
model is used to calculate the times to 
process the future workloads. Also, sensi- 
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tivity analyses can be made by varying the 
parameters, to see the effects on run time. 


Software physics approach. This ap- 
proach was developed by Kenneth Ko- 
lence, at the Institute for Software Engi- 
neering, Palo Alto, California. We dis- 
cussed the approach in our March 1978 is- 
sue. For more information on it, see Refer- 
ence 3. 

The approach is based on the concept of 
‘software work.’ An approximate definition 
of software work is: “A processor does one_ 
unit of software work on a storage device 
when it transfers one byte to that storage 
device.” 

Processing capacity is measured in terms 
of ‘software power,’ which is the ability of 
a processor to do software work per unit 
of time. Work is invarient, but power va- 
ries with the configuration. 

In using this approach, one first deter- 
mines the power of the hardware/software 
configuration under study—the cpu, the 
channels, the tape and disk drives, and so 
on. Initially, these power figures had to be 
determined using hardware and software 
monitors. But users have developed (and 
have exchanged among themselves) power 
tables for commonly-used hardware and 
system software. So determining the ca- 
pacity (power) of a configuration is not all 
that complex, for configurations covered 
by power tables, users have told us. 

The next step is to determine the 
amount of software work involved in the 
current workload and in the expected fu- 
ture workload. Again, these figures are ex- 
pressed in units of software work. These 
figures represent the demand for capacity. 

Programs are available for matching the 
demand-versus-supply of capacity, during 
typical daily operating hours. Results can 
be expressed as curves which show the 
amount of capacity needed to produce at 
least 95%, say, of the work on schedule. 

Thus, BEST/1 and software physics repre- 
sent objective, quantitative ways for esti- 
mating required future computer capacity. 


As we have said, capacity management 
is a complex subject. We plan to return to 
it, along with a description of some user 
experiences, in the not-distant future. 


But data processing management prob- 
ably can never provide (within budget) all 
of the capacity that users might desire. 
This is particularly true when interactive 
systems enter the picture. As workload be- 
gins to approach the capacity of a config- 
uration, response times get longer. This 
situation tends to happen during peak load 
periods, and users get frustrated as re- 
sponse times increase. Means are needed 
to shift workload away from the peak load 
periods and into the off-peak hours. One 
such means is the charging mechanism. 


Charging for services 


We discussed the subject of charge-back 
methods for computer services in our No- 
vember 1973, July 1974, and August 1975 
reports. Since that time, we have not come 
across any information that indicates that 
significantly improved methods have been 
introduced in the interim. So we believe 
that the discussion in those reports is still 
pertinent. Hence we will give only a very 
brief summary here. 


Most charge-back systems use average 
pricing, we gather from our discussions. 
That is, the cost of the overall service 
(hardware, software, staff, etc.) is divided 
by the total hours of usage in, say, one 
month. Users are then charged at that av- 
erage price per hour. All costs are thus re- 
covered and (ideally) the service ends up 
with no profit and no loss. 


Does this sound familiar? Does it seem 
practical? As we see it, this approach is fa- 
miliar to many people because it does 
seem ‘practical.’ But actually, it is a very 
poor method for charging for services. 
When usage is low, rates are high—dis- 
couraging more use. When usage does 
build up, rates drop—encouraging an ac- 
celeration of use. As usage approaches ca- 
pacity, rates reach their lowest point, en- 
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couraging more use. More capacity is 
brought in, and the cycle repeats. 

Instead of an across-the-board average 
pricing method, it would be much better 
to use a pricing method that encourages 
desired user behavior, we believe. When 
usage is low, set low prices to encourage 
more use; in such instances, the service 
probably will end up the accounting pe- 
riod with a deficit. As usage increases, 
change the price structure to encourage 
off-peak use. For interactive use during 
peak periods, not only would response 
times be longer but the resource usage 
charges per unit of time also should be 
higher. 

One advertisement we saw recently put 
the matter succinctly. The gist of the mes- 
sage was, “How much cpu time do you 
suppose is being spent in your shop by 
programmers playing ‘star wars’ games via 
Tso during peak load hours?” An effective 
charge-back system can help discourge 
such usage. 

If computer capacity has been planned 
well, and if there is an effective charge- 
back system in place that encourages de- 
sired user behavior, the problem of man- 
aging daily production still remains. Let us 
low at that now. 


Daily production management 


The scheduling and management of 
daily production in the medium size and 
larger data processing centers has been a 
complex job for a good number of years. 
And the problem is getting worse as the 
workload increases. Depending upon the 
organization size, there can be dozens, 
hundreds, or thousands of jobs daily. The 
sheer bulk of the workload adds to the 
complexity. 

But the size of the workload is only the 
beginning of the problem. Most data 
processing jobs are really parts of ‘job 
streams, with defined precedence relation- 
ships. For any given application system, 
there will be (1) at least one type of input, 
and generally several types, that must be 


made ready for data entry by a scheduled 
time, (2) data entry and the validation of 
input must then be performed, (3) errors 
detected by the validation check must be 
corrected and the transactions re-entered, 
(4) if all of this has been done at a remote 
site, the batch(es) of transaction data must 
be transmitted to the data center, (5) all 
input may be staged, to get it into the sys- 
tem, ready for processing, (6) sorting and 
processing is done, (7) output is staged and 
then printed, (8) the output documents are 
burst, decollated, collated, inspected, and 
bound, and finally (9) the output docu- 
ments are delivered to the users. 

Within this overall sequence, there are 
other precedence sequences that must be 
maintained. For batch processing, sorting 
of transactions must preceed file updating. 
Generally, too, any given transaction may 
affect several files; this is particularly true 
of the older, tape-oriented application sys- 
tems. So there can be a sequence of sort- 
update, sort-update, etc. Each update pro- 
duces outputs, some of which are printed 
and others of which flow into other sort- 
update sequences. 

So if some input does not arrive by its 
scheduled start time, a whole series of sub- 
sequent jobs can be affected. If that input 
is essential, then all subsequent jobs that 
rely on it will have to be delayed. And it 
would be very desirable to re-schedule, so 
as to make the best of the situation. 

The above discussion has dealt only 
with the scheduled production workload— 
the work that is known to come in on a 
regular basis. In addition, there is usually a 
fair amount of unscheduled work that 
must be performed in any data center. The 
general types of jobs may be known for 
this unscheduled work, but the specific 
jobs cannot be predicted in advance. An 
organization policy is then clearly needed: 
how soon will results be delivered to the 
users, after the input has been submitted, 
for (say) 95% of the unscheduled work? 
The policy might range anywhere from 30 
minutes to “as soon as we can do it.”” The 
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longer the users must wait, or the more 
variable the time that the results are deliv- 
ered, the more these users will want to use 
other services over which they have more 
control. 

The policy on handling unscheduled 
work probably will be based on both the 
volume of that work and its importance to 
the organization. For instance, in high 
technology manufacturing organizations, 
where engineering is a critical function, 
engineering computations probably will 
represent a substantial and important part 
of the total workload—and rapid response 
will be sought. In such an environment, 
computer capacity will be largely deter- 
mined by this unscheduled workload. If 
the unscheduled work is run during the 
daytime shift, and the scheduled work is 
run at night, the capacity needed for the 
unscheduled work may be more than 
enough for the scheduled workload. So 
handling perturbations in the schedule 
may not be difficult. 

But for most data centers, we gather, 
the bulk of the work is predictable, con- 
sisting of applications that are run on a 
regular basis. In this environment, com- 
puter capacity is chosen to handle the 
known workload. Not so much extra ca- 
pacity is available for handling perturba- 
tions. The need to schedule the predict- 
able workload becomes more intense. 

What are these perturbations? They are 
anything that disrupts the regular process- 
ing of the work. They include hardware 
failures, software errors, operator mis- 
takes, input that arrives too late, reruns, 
extra jobs with high priorities, peak loads, 
and so on. 

One approach to handling the predict- 
able workload and adjusting to the pertur- 
bations is that provided by Value Comput- 
ing, Inc. 


Scheduling daily production 


Value Computing, Inc., of Cherry Hill, 
New Jersey, has developed and is market- 
ing three major software products that are 


appropriate for our discussion. These are 
(1) an os/vs scheduler for use on IBM 360/ 
370 and plug-compatible systems, in con- 
junction with most of IBM's operating sys- 
tems, (2) a status and revision sub-system 
that keeps track of job status and supports 
revision scheduling, and (3) an automatic 
job submission sub-system. For more infor- 
mation, see Reference I. 


We will give a brief overview of these. 


OS/ VS scheduler. The heart of the 
scheduler is the ‘workload control file’ 
(wcF). The components of this file indicate 
VCI’s approach to scheduling. 


Job profiles. The job profile section of 
the wcF contains data about all scheduled 
jobs—those run daily, weekly, monthly, and 
such—for each data center that is being 
scheduled. All of the resources that are 
needed to perform a job, including the 
amount of a resource that is needed, are 
indicated. Really, streams of jobs are 
shown, giving the necessary sequence, 
from the submission of input to the deliv- 
ery of output. For each job within the 
stream, the profile indicates what re- 
sources must be available before the job 
can run. Also indicated are the time (and 
date) when input data will be available 
and the time when output must be deliv- 
ered. 


Work center profile. This portion of the 
WCF lists all of the resources that are being 
scheduled, by type and by location. It can 
include clerical positions, for data control 
and error correction, as well as operator 
functions for bursting, collating, binding, 
and delivery. All major computer re- 
sources, such as memory, disk drives, tape 
drives, etc. are specified. 

Yearly calendar. This part of the wcr 
indicates work days, week ends, holidays, 
etc. for up to one year in the future. 

Forecast workload. As daily schedules 
are generated (to be described), they are 
stored in this portion of the wcr. Sched- 
ules for up to 62 days in the future can be 
stored in detail. 
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Revision and comparison section. This 
part of the wcr holds today’s revised 
schedule(s), if any, plus the actual pro- 
duction results for the previous four sched- 
ules. 


The scheduler uses iterative simulation 
for the scheduling operation. That is, using 
the wcr, it attempts to load jobs into work 
centers, according to their start times; in 
doing this, it checks to see that all needed 
resources will be available at this simu- 
lated time. If a work center becomes over- 
loaded, some jobs may have to be moved 
ahead in the schedule so as to level the 
load. The objective is to get all jobs com- 
pleted by their target completion times 
and at the same time make efficient use of 
the resources. 


The scheduler can schedule all work sta- 
tions, not just the cpus. These include in- 
put preparation, data entry, staging, and so 
on. One study reported by VCI points up 
the need for this type of scheduling. This 
study found that the average time required 
by a data center—from the time that the 
user delivered input until the output was 
given to the user—was almost 15 hours. Of 
this time, 3 hours were consumed in input 
preparation, getting ready for entry into 
the computer. One hour was used for all 
computer processing. And then it took 
about 11 hours to print and distribute the 
outputs. Clearly, the big time losses occur- 
red before and after the computer process- 
ing. Just scheduling the computer could 
thus have relatively little effect, as far as 
service to end users is concerned. 


Using the wcr, the scheduler can ‘roll 
ahead’ for, say, one year to see what the 
workload looks like in the future. This can 
be useful for planning for additional com- 
puter capacity. 


The scheduling system also keeps track 
of actual resource usage and compares this 
with the expected resource usage, as de- 
scribed in the job profiles. If there is a sig- 
nificant variation between actual and ex- 
pected, the expected value is adjusted au- 
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tomatically. This adjusted figure in then 
used in future scheduling operations. 


The scheduling system provides a wide 
variety of outputs. One type, of course, is 
the daily schedule. Typically it is printed 
out, but is also available via a terminal. A 
daily actual versus schedule report high- 
lights the jobs that had significant varia- 
tions from schedule. Bar graph reports 
show the scheduled resource usage, etc. 


Status and revision. This sub-system 
(STARS) uses the schedule developed by the 
scheduling system and automatically up- 
dates a job status file for all cpu work, to 
show actual versus schedule. For non-cpu 
work, status data may be entered via a ter- 
minal. 


The sub-system monitors the progress of 
each job stream, making sure that all steps 
have been performed in their specified se- 
quence. If a job is missed, perhaps due to 
an operator error, this fact is reported by a 
message on the console. 


STARS provides input to the revision 
scheduling portion of the scheduler. If an 
operator who is monitoring production de- 
termines that a _ revision schedule is 
needed, almost all of the needed informa- 
tion is available in stars. It thus becomes 
feasible to reschedule numerous times a 
day, if the perturbations require it, so as to 
make as efficient use of the resources as is 
possible under the circumstances. 


STARS also allows end users to find out 
the current status of their jobs directly, by 
accessing via TSO Or ROSCOE. 


Job submission. This sub-system (APOLLO) 
is also driven by the scheduling system. It 
automates a portion of the computer oper- 
ator function. It stores job control (jcL) 
data and has access to the program library. 
When a job is in the job queue and its 
start time has almost arrived, APOLLO 
checks to see if all needed input resources 
are, in fact, available. If so, the data, JcL, 
and program are made ready for use by the 
computer. Jobs are thus submitted in 


EDP ANALYZER, JANUARY, 1980 


schedule sequence, reducing schedule per- 
turbations due to operator error. 

APOLLO also allows for on-line changing 
of jct and other control data. Further, 
manual job submission and entry of JcL 
can occur. An audit trail is made of all 
events, and an audit file of the current and 
six previous schedules, together with their 
JCL input, is maintained. 


On-line production control. VCI suggests 
that the production control system of the 
future will use all three of these packages, 
for dynamic control. The scheduler would 
be used to create the daily schedules. The 
jobs would be released automatically, ac- 
cording to the schedule. Actual job status 
would be determined. If perturbations oc- 
cur that require a revision of the schedule, 
that scheduling can take into account the 
actual status of all jobs. 

Let us now take a look at how one user 
organization uses these tools for managing 
daily production. 


Texas Instruments Incorporated 


Texas Instruments Incorporated, with 
headquarters in Dallas, Texas, is a major 
manufacturer and supplier of electronic 
components and equipment, mini- and mi- 
cro-computers, hand calculators, and digi- 
tal watches. Annual sales exceed $2.5 bil- 
lion and the company employs some 78,- 
000 people world-wide. TI has 39 manu- 
facturing plants in 18 countries. 

As we discussed in our September 1979 
report, TI is in the process of installing a 
world-wide distributed system. During the 
1970s, the company consolidated almost 
all of its data processing into the corporate 
information center (cic) in Dallas. The 
main goal of that consolidation was to re- 
move the incompatibilities of data and 
programs that had built up during the 
1960s, when the company had multiple 
data centers. 

In 1966, TI began installing a data com- 
munications network to its various sites. 
By 1976, the network was connected to 
most TI locations world-wide, with inter- 
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continental transmissions via __ satellite. 
Also, by 1973, TI management began to 
see the advantages of moving to a distrib- 
uted system. Since the incompatibilities 
had been largely eliminated, it appeared 
feasible to put processing power and data 
storage facilities at the end _ user 
locations—as long as corporate standards 
were observed. 

The distributed system structure has 
four levels. 

Level 1 is the cic in Dallas. Presently, it 
consists of four IBM 3033s and two 370/ 
168APs. The cic performs the bulk of TTI’s 
batch data processing, plus interactive da- 
tabase queries (via a and time sharing 
via TSO). 

Level 2 is in the process of implementa- 
tion. TI plans to use intermediate size IBM 
systems for this level, to be installed at 
major sites around the world, mainly man- 
ufacturing plants. These computers will 
provide interactive processing services, in- 
cluding database queries and time sharing. 
In addition, where appropriate, some level 
1 batch work will be off-loaded to these 
sites. 

Level 3 consists of local work-area com- 
puters that serve clusters of terminals. TI 
currently has 87 of these computers in- 
stalled world-wide. For this level, they 
have standardized on TI computers, pri- 
marily the TI 990 mini-computer (which 
uses the TI 9900 micro-processor). These 
level 3 computers provide the bulk of the 
interactive service. But some of them also 
provide remote job entry for batch work 
to be performed on higher level comput- 
ers. 

Level 4 is the work-station computers, 
for individual employee use. These gener- 
ally are intelligent terminals, and are used 
in an interactive manner. 


Managing the workload. In the present 
status of the TI distributed system, the 
bulk of the computing workload is batch 
work that is performed at the level 1 cic 
in Dallas. And, as just mentioned, some of 
the 87 level 3 computers serve as remote 
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job entry terminals for sending batch work 
to level 1 and for getting results back. 


In all, cic handles about 7000 jobs per 
day. Of these, some 1600 are predictable 
and are scheduled. These 1600 come from 
TI sites in North America, Europe, and 
the Far East. The remainder, the unsched- 
uled jobs, consist of engineering calcula- 
tions, program development and test, and 
ad hoc requests. Further, of these 5000+ 
unscheduled jobs per day, over 4000 occur 
between the hours of 7 AM and 7 PM Dal- 
las time. 


Most of the daytime hours—7 AM to 7 
PM—are reserved for the unscheduled 
work, in order to provide good service to 
these users. Most of the scheduled work is 
done at night. Further, the remote batch 
transmissions, both to and from Dallas, are 
scheduled, where appropriate. The sched- 
ules are created in Dallas, converted to re- 
mote site local times, and then transmitted 
to those sites. And when level 2 computers 
are installed, it is expected that the pre- 
dictable parts of their workloads also will 
be scheduled from Dallas. 


Because the unpredictable ‘workload 
dominates, TI determines its need for com- 
puter capacity largely from this workload. 
As it has worked out, the resulting capac- 
ity is quite adequate for handling the 
scheduled workload during the night shift. 


TI has experienced a rapid growth in its 
cic workload. In 1974, the center was han- 
dling about 250 scheduled jobs per day. By 
consolidating data centers plus the growth 
in usage, the load has grown since then to 
the current level of 1600 scheduled jobs 
(plus the 5400 unscheduled jobs) per day. 


Five years ago, the Dallas center 
workload was scheduled manually. But due 
to the rapid growth, manual scheduling 
was becoming impractical. So TI assigned 
some people to the center who had pro- 
duction control experience. They decided 
to automate the production control func- 
tion for the center. After considering sev- 
eral alternatives, including in-house devel- 
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opment, they chose the VCI scheduling 
system. 


This scheduling system soon brought the 
daily production under control, even with 
the rapid growth in the workload. So TI 
then began building a number of other 
production control tools in-house, to go 
along with the scheduling system. One tool 
was used to schedule the key punch func- 
tion. Another was developed to schedule 
financial closings for all TI accounting de- 
partments throughout the U.S. Still an- 
other tool was a system for automatic job 
submission. This one turned out to be the 
forerunner of VCI’s APOLLO sub-system. TI 
has since replaced their in-house system 
with APOLLO to avoid the need for in-house 
maintenance. 


TI has also installed VCI’s stars sub-sys- 
tem for tracking job status and for sup- 
porting revision scheduling. 


With all of these production control 
tools, what have been the results at TI? 
Well, computer operations carefully moni- 
tors production performance, such as re- 
port deliveries. For a recent 52 week pe- 
riod, in only three weeks did they fail to 
deliver at least 95% of all reports on 
schedule. They also track 40 to 50 key jobs 
daily, most of them manufacturing control 
jobs. Here the goal is even more challeng- 
ing. If any report is four or more hours 
late in a week, the performance is consid- 
ered unsatisfactory. Over 95% of the key 
daily systems have acceptable perform- 
ance, on a consistent basis. 


In all, the people in computer opera- 


tions monitor some 250 performance mea- 
sures. The responsibility for this monitor- 


ing is spread throughout the organization. 
As the people in computer operations see 
it, they are very service oriented and they 
feel that they are meeting their perform- 
ance goals. A part of the credit, they say, is 
due to the use of their production control 
tools. 

But good performance is not just a func- 
tion of these tools, we were told. Com- 
puter operations must also get co-opera- 
tion from the end users. TI’s charge-back 
system helps, they say. Different prices are 
charged for different priorities on different 
resources. On the average, resource prices 
that are charged for users have been going 
down steadily every year. But for specific 
resources in tight supply, prices can rise 
for a time. By charging different prices for 
different times of the day, peak loads are 
levelled somewhat and users can save 
money by making use of off-peak hours or 
longer delivery times. 

As our interview was closing, one re- 
mark proved to be the ‘frosting on the 
cake.’ For the past five years, TI’s com- 
puter workload has grown as described 
above. But the production planning and 
control staff budget has stayed practically 
flat over that period. Which speaks well 
for automated tools for computer 
workload control, we would think. 
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